The exec span on the durable-object side stays open until the handle
stub reports how it was consumed, and only result(), stream(), and
disposal reported. A Worker that signalled a command and walked away
left the span open and the child's bracket unresolved for the life of
the session.

kill() now settles the span too. Settling is separate from claiming
the handle: the signal doesn't drain anything, so a caller can still
collect the output of the killed run through result(). The first
terminal path to arrive describes the span's outcome, which for a bare
kill means no exit code and no sync counts.

A command outlives the request that started it, but only a caller
inside the durable object could say so. WorkspaceShell.get reattaches
by exec id; the shell stub exposed no such method, so a Worker that
lost its handle stub — a new request, a dropped connection — lost the
run with it. The rebuilt handle didn't even carry an id to reattach
with.

The stub gains get(id, options), forwarding encoding, resume, and the
backend selector to the host shell, and the client gains the matching
overloads. Reattach runs no push/pull bracket and so opens no span, so
the handle stub it returns is built with a consumer nobody reads and a
span that has already closed.

The client now addresses every run by an id it knows: the caller's own,
or a minted UUID when the caller doesn't care. That id lands on the
rebuilt handle as `id`, matching the host ExecHandle, so a Worker can
hold onto it and reattach later.

A run in the container streams to one subscriber at a time, and the
slot only frees when that subscriber cancels. The handle keeps two
readers on the event stream: the caller's, and a second one watching
for the exit event so kill() can promise the child has gone. They come
from a tee, and a tee holds its source until both branches cancel — so
dropping a handle left the container still streaming to a reader
nobody would read, and a later get() on the same run was refused for
the rest of the run. Awaiting the caller's own cancel() never returned
for the same reason.

The caller's branch now takes the watcher with it: cancelling the
handle abandons the watch, both branches go, and the wire stream
cancels through to the container. The documented flow — start a long
command in one request, reattach in a later one — works as long as the
earlier handle was dropped, which the stub's disposal does.

Both tests stand in for the container's subscriber bookkeeping, which
the existing fakes don't model: one exec-then-reattach at the shell
level, one across the stub to cover disposal.

Killing a command mid-stream reported the wrong outcome. The exec span
closes on the first terminal path, and kill() counted itself as one
even when a result() or stream() was already reading the handle: the
span recorded exit code -1 and zero sync counts while the reader went
on to observe the real exit code off the wire.

A reader in flight now owns the outcome. kill() only closes the span
when nothing claimed the handle, and it no longer waits on a span that
closes whenever the caller finishes reading.

Two smaller things the same review turned up. The shell stub now
rejects a spawn that came back under an id other than the one asked
for: the client addresses runs by an id it mints, so a backend
substituting its own would hand callers an id that get() can't
reattach with. And the reattach path's disposal gives the subscription
back rather than stopping the command — it didn't start it — which the
comment now says.